Add federated authorization tutorial - #576
Conversation
Adds a tutorial showing how to federate authorization across multiple identity providers (Keycloak OIDC + GitHub OAuth) by binding each external account to a canonical internal SpiceDB user. Includes the architecture diagram and links to the runnable demo in authzed/examples. Signed-off-by: Sohan Maheshwar <1119120+sohanmaheshwar@users.noreply.github.com>
|
Preview deployment status for this pull request.
|
| The check names a `user`, not a Keycloak or GitHub account. | ||
| Authentication is upstream; this is downstream. | ||
| They meet at the `user` id and nowhere else. |
There was a problem hiding this comment.
I'm not sure if this is the level of detail you want to get to, but this requires the authentication layer to have the mapping as well, because otherwise the calling application doesn't have this association. At $PREVIOUS_JOB we had a set of bindings between Auth0 and our application server that then attached this internal user ID as a custom claim on the JWT. Otherwise you do want to check using the identity provided by the IDP, and ideally you note the IDP ID associated with the user somewhere in your application for administration purposes.
| </Tabs> | ||
|
|
||
| That returns everything reachable through any path (owned, editor, or viewer) without those rules living in your app. | ||
|
|
There was a problem hiding this comment.
General note: I think it's worth calling out the work required to associate users from different identity providers - otherwise the internal user ID is just a layer of indirection.
Addresses review feedback: avoid two sequential callouts by nesting each warning under the list item it pertains to. Signed-off-by: Sohan Maheshwar <1119120+sohanmaheshwar@users.noreply.github.com>
2 participants
What
Adds a new tutorial: Federate Authorization Across Multiple Identity Providers (
spicedb/tutorials/federated-authorization).It walks through using SpiceDB to centralize permissions when users authenticate through different identity providers (Keycloak OIDC + GitHub OAuth): each external account (
keycloak_account,github_account) binds to a canonical internaluser, and documents reference only thatuser— so the authorization model is unaffected by which IdP a user came from.Contents
*_account → bound_to → userbinding patternzedand Python examples for grant / check / share / lookupZedToken/at_least_as_fresh)authzed/examples/federated-authorizationAdded to the Tutorials nav via
app/spicedb/tutorials/_meta.ts.Note
The link to
authzed/examples/federated-authorizationresolves once authzed/examples#48 merges.